M-Bus to NB-IoT
Integration manual for the ACRIOS Systems converters ACR-CV-101N-M-D and ACR-CV-101N-M-EAC.
Introduction
This is the documentation for the ACRIOS Systems M-Bus to NB-IoT converter. The documentation refers to this Lua script and covers possible configuration options.
Typical Use-Case
Efficient monitoring and management of heat meters and other M-Bus devices plays a key role in optimization of energy and resource consumption. The integration of the M-Bus to NB-IoT converter presents a solution that allows for quick deployment and seamless connectivity, real-time insights and efficient control.
Key benefits of our devices:
- Time and Cost Savings: The quick installation process eliminates extensive configuration and wiring efforts, reducing installation time and associated costs.
- Seamless Integration: The plug-and-play nature of the solution simplifies the integration of heat meters into the district heating network, minimizing disruption to residents.
- Reliable Communication: The external antenna ensures reliable signal propagation, maintaining consistent communication even in complex urban environments.
- Real-Time Insights: The solution provides real-time heat consumption data, enabling accurate billing and informed decision-making for energy optimization.
What Is M-Bus?
M-Bus (Meter-Bus) is a European standard (EN 13757-2 physical and link layer, EN 13757-3 application layer) for the remote reading of water meter, gas or electricity meters. M-Bus is also usable for other types of consumption meters. The M-Bus interface is made for communication on two wires, which is very cost-efficient. There is also a radio variant of M-Bus (Wireless M-Bus), specified in EN 13757-4.
Data on the M-Bus is transferred in telegrams which consist of one or more frames, there must not be any pauses within telegrams, not even after stop bits. M-Bus uses four different telegram formats with following structures:
| Single Character | Short Frame | Control Frame | Long Frame |
|---|---|---|---|
| E5h | Start 10h | Start 68h | Start 68h |
| C Field | L Field = 3 | L Field | |
| A Field | L Field = 3 | L Field | |
| Check Sum | Start 68h | Start 68h | |
| Stop 16h | C Field | C Field | |
| A Field | A Field | ||
| CI Field | CI Field | ||
| Check Sum | User Data (0-252 Byte) | ||
| Stop 16h | Check Sum | ||
| Stop 16h |
When communicating with more meters on the same M-Bus line, it is crucial to provide each slave unit with individual address (A Field). Meter can be addressed by its primary address or by its secondary address.
Primary Addressing:
| Address | Function |
|---|---|
| 0 | Factory default address. |
| 1-250 | Addresses that can be assigned to slaves. (Primary addresses) |
| 251-252 | Reserved for future use. |
| 253 | Indicates that addressing is performed at the network layer instead. (Secondary addressing procedure) |
| 254 | Broadcast, meters reply with their addresses. (This causes collision, used for test purposes only.) |
| 255 | Broadcast, meters do not reply. |
The secondary address consists of 4 parts:
- 4 bytes is the device ID (serial number)
- 2 bytes is the manufacturer’s identifier
- 1 byte is the device version
- 1 byte is the device media
The benefit of secondary addressing is that there is no need to reconfigure meter’s primary addresses and the installation can be navigated only by modifying the converters’ addressing mechanism.
Converter Integration
Functions
- Configurable reading period (default interval: 2 h 30 min)
- Configurable initial M-bus delay (default length: 4 000 ms -> 4 s)
- Configurable amount of retries (default amount: 2)
- Configurable amount of read-out devices (up to 16 devices)
- Configurable M-Bus parameters
- Configurable port and other connection parameters
Out of the Box Behavior
After connecting the meter to the converter, the device sends a broadcast query by default to address 254 and received data are forwarded to the NB-IoT network in its original format.
If the meter is not responding, the payload “NO DATA RECEIVED” in its HEX format 4E 4F 20 44 41 54 41 20 52 45 43 45 49 56 45 44 is received in the transmission.
Read-Out Example Using Engelmann SensoStar U
Payload From M-Bus meter:
00 : 68 B3 B3 68 08 00 72 98 53 85 30 C5 14 00 0A 8D
10 : 10 00 00 04 78 E6 D0 D6 01 04 06 00 00 00 00 04
20 : 13 00 00 00 00 04 2B 00 00 00 00 14 2B 00 00 00
30 : 00 04 3B 00 00 00 00 14 3B 00 00 00 00 02 5B 18
40 : 00 02 5F 18 00 02 61 C9 FF 02 23 B9 00 04 6D 08
50 : 2A FC 28 44 06 00 00 00 00 44 13 00 00 00 00 42
60 : 6C 00 00 01 FD 17 10 03 FD 0C 05 00 00 84 20 06
70 : 00 00 00 00 C4 20 06 00 00 00 00 84 30 06 00 00
80 : 00 00 C4 30 06 00 00 00 00 84 40 13 00 00 00 00
90 : C4 40 13 00 00 00 00 84 80 40 13 00 00 00 00 C4
A0 : 80 40 13 00 00 00 00 84 C0 40 13 00 00 00 00 C4
B0 : C0 40 13 00 00 00 00 95 16
M-Bus Payload Parsing
The payload itself is in a form of typical M-Bus frame, including the header. Any M-Bus parser can be used but we recommend using one of the parsers below. Please always check for a possible licensing model.
💡 Alexander Miller M-Bus parser
💡 libmbus - M-bus Library from Raditex Control
Here is an example using docker to run libmbus service.
Hardware Used
- ACR-CV-101N-M-D - M-Bus to NB-IoT converter, battery powered
- ACR-CV-101N-M-EAC - M-Bus to NB-IoT converter, externally powered
The converter allows connection to any meter or other device equipped with M-Bus communication.
Hardware Limitations
- The hardware allows you to connect up to 16UL (5UL for a legacy version). 1UL equals to 1.5mA. Please note that 1UL is not always a representation of one meter because some meters may require 2UL or even more. This information can be found in the documentation of the M-Bus meter itself.
- Do not connect 2 M-Bus masters at once.
- Here is an estimate for a following scenario. For more accurate calculations please use the calculator tool.
We have 2 slave units of the 2.5UL size connected to the converter. The preheat time is 4 seconds (default). We are also using a single D battery (double D2 battery would power the device twice as long).
| Reading and Sending Interval | Estimated Battery Lifetime |
|---|---|
| 1 hour | 2 years |
| 2 hours | 4 years |
| 6 hours | 10+ years |
The longer preheat time - initialDelay in the script - means higher power consumption. Make sure to reduce it to necessary length in order to save up battery. This should not affect externally powered version but battery versions may suffer from increased power consumption.
Imagine a meter needs 2 seconds of preheat time, therefore 2.5 seconds should ensure smooth operation while reducing battery consumption.
In case of a longer M-Bus connection (approximately 380 meters between the meter and converter), a termination resistor (5.5 kohm) is required. This applies only to new generation (NG) of M-Bus converter (the device that allows up to 16 UL), low amount of UL and long connection (for example 380m).
Application Limitations
- M-Bus communication has to address individual meters separately when more than one device is connected, either via primary or secondary addressing.
Device Configuration Using Lua
Lua scripting language is used to configure our devices. It is an effective tool for dynamic device customization, easy to use but also fit for advanced users, who would like to fully configure their devices.
The default script for M-Bus to NB-IoT converter can be found on the following link:
https://sw.acrios.com/acrios/acr-cv-lua/-/blob/master/ACR_CV_101N_M_X_nbiotMbus.lua
Configuration of Basic M-Bus Parameters
Many key parameters of the device can be customized here, such as:
- Wake-up interval
- Transmit port
- Baudrate
- Amount of retries when reading
- And others, please see below:
Two dash symbols in Lua allows to comment a code.
--This is a note.
---- CONFIGURATION ----
version = "2.2"
------- NB-IoT --------
APN = "auto" -- "auto" is autodetection per SIM, use "nb.m2mc" for Miotiq
PLMNID = "0" -- 0 is autodetection per SIM, use 23003 for Vodafone CZ explicit settings
protocol = "UDP" -- UDP or TCP
ip = "192.168.0.20"
port = 4242
receiveTimeout = 15000 -- the maximum execution time in milliseconds
-- No communication watchdog
-- Reset if no downlink message is received from the server/backend at least once per specified time
noComWdg = 24*3600*1000 -- 1 day
------- M-BUS ---------
baudrate = 2400 -- baudrate: up to 921600 baud
parity = 2 -- communication parity: 0 for none, 1 for odd and 2 for even parity
stopBits = 1 -- number of stop bits: 1 or 2
dataBits = 8 -- number of data bits: 7 or 8
initialDelay = 4000 -- delay before sending request - some devices require 3000 (Engelmann SensoStar), impacts battery life!
timeout = 3000 -- request timeout in ms
retries = 2 -- number of retries
------ Power ---------
mbusLevelOffset = nil -- expert settings - leave nil for automatic compare level for 16UL hardware version
minimumVoltage = 3150 -- in mV, minimum voltage before proceeding to MBus request
targetVoltage = 3400 -- in mV, in case charging has to be done, stop at this voltage
minimumVoltagerRise = 10 -- in mV - in case voltage does not rise at least by this value, proceed to MBus request
supercapChargingTimeout = 5*60 -- in seconds, maximum timeout waiting for SC to charge
supercapChargingTimeStep = 30 -- in seconds, wake up every x to check the voltage
------ Timing ---------
--- wakeup interval ---
periodHours = 2
periodMinutes = 30
-----------------------
Primary Addressing of a Single Meter
The code needed to configure single meter readout can be found on the line #110 of the default script. By default, the address to which the connected device should answer is address 254.
If the device is not answering, you might want to check the initialDelay parameter under the configuration and set it to a higher value. The initialDelay is a time for which the M-Bus is being powered on but with no activity. Some meters require this time to be at least two seconds long but the times may vary (up to six seconds).
From our experience the Engelmann devices requires three seconds and the Schneider Electric devices iEM requires up to six seconds.
Example of M-Bus Query - Address 254 (0xFE)
b=pack.pack('<b5', 0x10, 0x7B, 0xFE, (0x7B+0xFE)%256, 0x16)
status, c, a, ci, _, raw = api.mbusTransaction(b, timeout, retries)
-- CREATE MBUS QUERY --
-- MBUS Query is being assembled as described in MBUS protocol documentation.
-- In the example below broadcast adddress 254 (=0xFE) is used.
-- Documentation: https://m-bus.com/documentation-wired/05-data-link-layer
-- Request for Class 2 Data - REQ_UD2
-- b=pack.pack('<b5', 0x10, 0x5B, 0xFE, 0x59, 0x16)
-- 0x10 - Start byte
-- 0x5B or 0x7B - C-Field - Request for Class 2 Data
-- 0xFE - Address field
-- 0x59 - CRC - calculated by (0x7B+0xFE)%256
-- 0x16 - Stop byte
Address 254 is used as an universal broadcast address to which any meter answers. It is effective in such cases, when reading from a single connected meter, because there is no need to deal with primary addressing.
Example of M-Bus Query - Address 1 (0x01)
b=pack.pack('<b5', 0x10, 0x7B, 0x01, (0x7B+0xFE)%256, 0x16)
status, c, a, ci, _, raw = api.mbusTransaction(b, timeout, retries)
-- CREATE MBUS QUERY --
-- MBUS Query is being assembled as described in MBUS protocol documentation.
-- In the example below broadcast adddress 254 (=0xFE) is used.
-- Documentation: https://m-bus.com/documentation-wired/05-data-link-layer
-- Request for Class 2 Data - REQ_UD2
-- b=pack.pack('<b5', 0x10, 0x5B, 0xFE, 0x59, 0x16)
-- 0x10 - Start byte
-- 0x5B or 0x7B - C-Field - Request for Class 2 Data
-- 0x01 - Address field
-- 0x59 - CRC - calculated by (0x7B+0x01)%256
-- 0x16 - Stop byte
Primary Addressing of Multiple Meters
The device allows you to connect up to 16UL (5UL for a legacy version). 1UL equals to 1.5mA. Please note that 1UL is not always a representation of 1 meter as some meters might require 2UL and in some cases even more. This information should be stated on the documentation of the M-Bus meter itself.
Example of M-Bus Query - Primary Address 1 & 2 (0x01 and 0x02)
-- CREATE MBUS QUERY --
b1=pack.pack('<b5', 0x10, 0x7B, 0x01, (0x7B+0xFE)%256, 0x16)
b2=pack.pack('<b5', 0x10, 0x7B, 0x02, (0x7B+0xFE)%256, 0x16) --> New line has to be added
-- Set the name of the variable to be different -> b2, and change the address of the device -> 0x02
status, c, a, ci, _, raw1 = api.mbusTransaction(b1, timeout, retries)
status, c, a, ci, _, raw2 = api.mbusTransaction(b2, timeout, retries) --> New line has to be added
-- Set the name of the variable containing the data to be different -> raw2
-- And reference correctly the variable in the arguments -> b2
raw = raw1 .. raw2 -- Now combine all the raw variables into one
Read out of Two Meters & Both Answer
This is a readout of the two connected devices on addresses 0x00 and 0x0B. The data from both of the devices is contained in a single readout and it is possible to filter them by searching for a valid M-Bus frame starting with “68” and ending with “16”.
From M-Bus Meter:
00 : 68 56 56 68 08 0B 72 14 05 00 15 77 04 14 03 37
10 : 30 00 00 0C 78 14 05 00 15 0D 7C 08 44 49 20 2E
20 : 74 73 75 63 0A 37 30 34 33 30 30 42 42 35 31 04
30 : 6D 27 0A FD 28 02 7C 09 65 6D 69 74 20 2E 74 61
40 : 62 F2 08 04 13 CE 00 00 00 04 93 7F 00 00 00 00
50 : 44 13 CE 00 00 00 0F 10 02 1F 87 16 68 B3 B3 68
60 : 08 00 72 98 53 85 30 C5 14 00 0A C5 10 00 00 04
70 : 78 E6 D0 D6 01 04 06 00 00 00 00 04 13 00 00 00
80 : 00 04 2B 00 00 00 00 14 2B 00 00 00 00 04 3B 00
90 : 00 00 00 14 3B 00 00 00 00 02 5B 17 00 02 5F 17
A0 : 00 02 61 0C 00 02 23 BA 00 04 6D 32 28 FD 28 44
B0 : 06 00 00 00 00 44 13 00 00 00 00 42 6C 00 00 01
C0 : FD 17 10 03 FD 0C 05 00 00 84 20 06 00 00 00 00
D0 : C4 20 06 00 00 00 00 84 30 06 00 00 00 00 C4 30
E0 : 06 00 00 00 00 84 40 13 00 00 00 00 C4 40 13 00
F0 : 00 00 00 84 80 40 13 00 00 00 00 C4 80 40 13 00
00 : 00 00 00 84 C0 40 13 00 00 00 00 C4 C0 40 13 00
10 : 00 00 00 39 16
Read out of Two Meters & Only One Answers
This is a readout of the 2 connected devices on addresses 0x00 and 0x0B, but only the data from a single communicating device has been forwarded. It is possible to identify the device by its header within the M-Bus protocol.
From M-Bus Meter:
00 : 68 56 56 68 08 0B 72 14 05 00 15 77 04 14 03 38
10 : 30 00 00 0C 78 14 05 00 15 0D 7C 08 44 49 20 2E
20 : 74 73 75 63 0A 37 30 34 33 30 30 42 42 35 31 04
30 : 6D 30 0A FD 28 02 7C 09 65 6D 69 74 20 2E 74 61
40 : 62 F2 08 04 13 CE 00 00 00 04 93 7F 00 00 00 00
50 : 44 13 CE 00 00 00 0F 10 02 1F 91 16
Read out of Two Meters & None Answers
This is a readout of the two connected devices on addresses 0x00 and 0x0B. If there is no answer, you are going to receive only following message: “NO DATA RECEIVED”.
From M-Bus Meter:
00 : 01 01 4E 4F 20 44 41 54 41 20 52 45 43 45 49 56
10 : 45 44
4E 4F 20 44 41 54 41 20 52 45 43 45 49 56 45 44 HEX = NO DATA RECEIVED ASCII
Troubleshooting & FAQ
Device is not connecting to the Network Server
- Make sure that the inserted keys are correct, that the device configured in OTAA and check whether the AppEUI is required. If AppEUI is required, please use the same “0” -
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.
Device is sending unknown payload
- Please check if the payload is
4E 4F 20 44 41 54 41 20 52 45 43 45 49 56 45 44- this translates to “NO DATA RECEIVED” in ASCII.
Device is still sending NO DATA RECEIVED
- Please check if the M-Bus baudrate and parity configuration is correct and if the electrical connection is done properly. You can also try to change parameter
initialDelayto a larger value as some meters require up to 6 seconds = 6000 ms. Make sure that no more than one device is connected without any prior changes to configuration.
Device is not connecting to the GUI
- Make sure to use the Chromium based browser, we strongly recommend to use Google Chrome (other Chromium based browsers still may cause unexpected issues). Also make sure that the serial line is not opened in any other serial line monitor.
Device has connected, Lua script was uploaded but it is not possible to connect anymore
- Make sure the battery has been disconnected for a longer period of time to discharge the capacitor or alternatively short the battery pins on the PCB. Connect two metal pins in the battery connector on the PCB with something conductive (tip of screw driver, paper clip, tip of a pen…). The device can connect only when in bootloader or when it is sleeping. If the device is in the application Lua script and currently running, it will not connect.
Where do I configure the Lua script?
- Please, make sure to use a Chromium based browser, we strongly recommend to use Google Chrome.
Where can I see a data or serial line log?
- You can check any serial line monitor such as PuTTy or Termite. Please make sure the serial line monitor configuration is - baud rate: 115 200, data bits: 8, stop bits: 1, parity: none.
I am getting a one-byte answer. What does it mean?
- The 1-byte answer usually means there is a collision on the M-Bus line. This usually occurs when more than one M-Bus meter is connected and the M-Bus converter is sending a broadcast query on address 254. The exception might be a “0xE5” which is a confirmation from the meter according to M-Bus standard.
I want to have a possibility to remotely configure hardware and the Lua script. How can I do it?
- You can either take a look at our documentation that is available at wiki.acrios.com and modify the Lua script by yourself or you can contact our support at support@acrios.com. We are gladly going to point you in the right direction.